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THE BCC 500 COMPUTING SYSTEM; 
AN INTRODUCTION AND OVERVIEW 



1.0 INTRODUCTION 



This document describes the architecture of the BCC 500 
system, stressing its multiprocessor structure and the 
effects of this structure on the organization and implemen- 
tation of the BCC 5 00 operating system. Details of the 
system's hardware components and descriptions of various 
aspects of the user machine provided by the system are found 
in other documents and papers [^Wi^fHrawft list of refer- 
ences!, in order to give the reader some orientation, how- 
ever, the remainder of this section is devoted to a short 
account of the system's origins. Brief mentions of its 
intended uses, its user machine features, and its hardware 
structure are given in Appendix I. 



1 . 1 Background 

The architecture of the BCC 500 system was largely 
determined by a design team working under Project GENIE at 
the University of California, Berkeley in 1968 (another list 
of old Genie references, 6700 documents, Van Tuyl's thesis, 
etc.]-. The project's goal at that time was to develop a 
basic, cost-effective resource-sharing system structure 
which could serve as the nucleus for a number of operating 
systems tailored to specific applications areas. 



-The Project was associated with several commercial 
organizations in a joint venture to produce what was then 
termed the SCC 6700. 
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In 1972 the company's hardware assets -- including the 
500 prototype — were purchased by the University of Hawaii, 
and the equipment was dismantled and moved to Honolulu, 
where it was refurbished and reassembled by THE ALOHA SYSTEM 
Project to be used as a research and computing tool. The 
system became active again in February 1973, and it has been 
used since that time by the Project, yy other ARPA 
contractors (via the ARPA network) and in classes of the 
Department of Electrical Engineering. 
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2.0 SYSTEM ARCHITECTURE 
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Figure l. BCC 500 System. 



The six processors are built almost identically. In 
the system they are individually dedicated, however, to 
various roles. The nature of this dedication and its 
implications are among the more interesting aspects of the 
system architecture. Two of the processors have enhanced 
hardware capability and are used to implement the more 
visible aspects of the virtual machine; they are called 



Page 



accordingly CPUs (although the term is not entirely apt in 
this context). The other processors are dedicated to 
various tasks of resource allocation. 
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2.1 Processor Assignments 

Figure 2 shows the names of the 500 system processors 
and suggests their assignments. 



Figure 2. BCC Central-site Processor Assignments. 
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of others which are convenient to the user. This 
system -provided code is considered to be logically 
a part of each user's job - called £rocess in our 
terminology -- and is shared by all processes. It 
is fully protected by various CPU hardware 
features; it cannot be inspected or modified by 
user code, but only entered at discrete entry 
points implemented as system tills.. These calls 
take on the nature of virtual machine 
" instructions*" checking carefully the user's 
intended actions and his authority to do them 
before interacting in any way with the rest of the 
system . 

Beyond the protection mechanisms alluded to 
above the instruction and addressing capabilities 
of the CPUs are of little importance to the system 
architecture. In this system virtually any CPU 
could be used (assuming hardware compatibility 
with the memory system and the requisite 
protection mechanisms). 



CH_1P_ 

The CHaracter-or ien ted I/O processor has, two 
main functions: (1) to communicate and manage the 
terminals which may be connected to the system, 
and (2) to perform a number of functions related 
to dynamic buffering of character I/O streams to 
and from the user processes on the CPUs. 
Originially the CHIO was designed to communicate 
with a number of remotely located computers termed 
Data communication Computers (DCCs) to which the 
actual terminals were connected. Thus in 
connection with (l) the CHIO was to supervise and 
control the various DCCs, load their local 
memories, multiplex I/O for individual terminals, 
acknowledge correct receipt of packets from DCCs, 
initiate retransmissions to DCCs, etc. In Hawaii 
it was not necessary to implement a full-scale 
communications network just to accommodate the 
local terminals; they were wired directly to the 
CHIO processor and its activities were modified to 
deal with the terminals directly. Remote 
terminals are accommodated by means of the ARPA 
network, which is interfaced to the 500 system 
through the CHIO processor which communicates via 
a wired connection to an IMP port on the network's 
ALOHA-TIP. 
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SCHED 

The s_CJLE.Hul ing processor's principal function 
is to schedule the two CPUs amongst the various 
active processes. Thus it is responsible for 
fielding wake up conditions as they are generated 
and for making decisions on the order in which 
processes are passed through the central memory 
from, say, drum where they commonly reside. This 
information is passed to the memory management 
portion of the system for appropriate action. On 
a different level of activity the SCHEDuler makes 
final decisions as to which of several processes 
ready to run in the central memory is assigned to 
each CPU. This decision is normally made as the 
process on each CPU blocks. It is possible for 
the SCHEDuler to pre-empt a running process on a 
CPU; this does not normally happen, as the 
algorithms for scheduling are designed to permit 
CPU tasks normally to dismiss themselves or run to 
the end of a preset time interval. The SCHEDuler 
generates its own real-time wakeup conditions. 



KMP 

The memory Management Processor * is 
responsible for management of the entire system 

memory. We define memory here to include the 
contents of drum and disk as well as central 
memory. The MMP together with the storage under 
its control can be viewed as a separate system 

with a table-driven interface to the rest of the 
500 system. The memory system is described more 
fully in Section 2.3 below. Here we simply point 
out that the function of the MMP is to get the 
right information into the right place at the 
proper time. 



SMP 

The s_ystem monitoring processor continuously 
monitors a number of indicators which are set on 
the occurrence of some malfunction. It is 
equipped with a number of special control lines 
leading to the other processors and has the 
ability to control these processors as well as 
monitoring the system's health. The SMP may thus 
effect automatic crash recovery procedures, in 
many cases before significant damage to the con- 
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1.2 Realization of the Dedicated Functions 
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It was decided early in the 500 system design to place 
the dedicated functions of each processor directly into the 
processor microcode. This gives a distinctive cast to the 
system, as it means in effect that the bulk of the operating 
system exists in the processor hardware (more precisely, the 
iiXl 1 ax e 1 . Clearly, the processors operating in this mode 
have high capability (their instruction bandwidth is high 
since they refer to memory only for data). But the 
operating system algorithms are difficult to change, as the 
ROMs can be modified only by removing and inserting diodes. 

The difficulty of changing the microcode may be viewed 
as a beneficial constraint. It is the same constraint that 
requires a hardware designer to exercise extreme care and 
regularity in his designs, yielding results which are more 
nearly correct and more maintainable. Yet, it is probably 
unfair to press the analogy too far. Thus, in each proces- 
sor there is found microcode which, in more classical 
fashion emulates the instruction set of a simple, 
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conventional processor. This microcode goes to memory for 
instruction fetching for the emulated processor? and thus 
each processor can execute conventional software. 
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2.3 The Memory System 
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Figure 3. BCC 500 Memory System. 



in Figure 4 we note that user programs (more precisely, 
processes) found in the CN may be classed into one of four 
categories : 
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1) incoming processes (partially loaded) 

2) fully loaded processes (ready to run) 

3) active processes (being run by a CPU) 

4) outgoing processes (partially unloaded). 



clearly the individual processes do not move physically 
through the CM as Figure 4 suggests. 



Figure 4 . conceptualization of the Memory system operation. 



They are placed into randomly available page slots by the 
>*« and mapped into their proper position in the logical 
address space by page maps associated with each CPU. To 
facilitate the handling of pages in central memory* the data 
format on the drums and disks was designed so that pages are 
the only unit of information treated as addressible entities 
within the memory system. 
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The •**& writes out process pages at any sector address 

currently available and under the read/write heads; 

similarly it reads in processes in the order in which a 

process's pages happen to come under the heads. 

The identity of the pages in a given process working 
set together with their location in the memory system is 
maintained by the T»€ in various resident tables in the CM. 
(This space is not shown in Figure 4.) The ffW^ must refer 
to these tables constantly and to the rotational position of 
each of the 16 rotating devices in order to keep the flow of 
pages moving at an optimum rate. 
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3.0 SYSTEM OPERATION 



The purpose of the system is to provide an environment 
for the execution of user processes which, in turn, 
typically access and modify user files. Processes and files 
are thus principal system objects consisting of pages of 
information contained within the memory system together with 
additional descriptive information. The process consists of 
system code shared with all processes (that code which 
communicates with the management processors), system code 
which may be unique to. the process or shared with a number 
of other processes, user code, and all variable storage. It 
also includes a so-called c.p.jile.ii. klo_ c_£ containing the CPU 
state when the process is inactive, unique names of all the 
process pages, constitution of the present working set of 
pages (those pages which must be loaded into central memory 
before the process can be considered for activation), and 
mapping information. The file consists of those pages 
holding the file's contents plus directory information, 
again naming the pages and ordering them within the file. 

The files can be created and destroyed (by processes)? 
in the meantime they reside permanently within the system. 
The place of residence of inactive files is, of course, 
disk. when files are accessed the memory system moves them 
first to drum and then to central memory for the actual 
access. As the file is no longer accessed and room on the 
drum is needed for new files or processes, the file is moved 
by the memory system back to disk. 

Processes are created by a single system subprocess by 
user request, usually when he logs into the system. Each 
process has a subprocess structure to facilitate both the 
system design and the needs of the user. The structure is a 
simple, linear one in which each subprocess is the inferior 
of at most one other subprocess and in turn is (immediately) 
superior to at most one subprocess. Subprocesses may have 
their own memory spaces or may share portions or all of 
memory with other subprocesses. They may communicate by 
means of messages passed through shared memory or by (soft- 
ware) interrupts. At the end of a computation the process 
terminates itself or is terminated by the user when he logs 
out. An option permits the user to log out of the system, 
leaving his process undestroyed but in a dormant state. The 
process then takes on the nature of a file, i.e., it takes 
on a symbolic name and is placed in a directory for later 
reference. At a later time a similar option at log-in 
permits the user to re-attach himself to the dormant process 
or establish a new one. 
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It has been implied in all of the foregoing what each 

of the processors does with respect to a process or a file. 

we state here more explicitly the activities of each 
management processor relative to processes and files. 



The CHIO passes character streams between 
processes and I/O terminals. it also passes files 
between the system and external storage media such 
as magnetic tape or special I/O devices such as 
line printers. The CHIO processor also commun- 
icates with the arpa network. 



SCHEI) 

The SCHEDuler selects processes for running 
and directs this information to the MMP, It also 
attaches processes loaded and ready to run to 
CPUs. It does this by placing a pointer to the 
process context block in a special central memory 
location and setting a request latch in the given 
CPUt which then proceeds to load its own state 
from the context block and resume computation. 
The SCHEDuler sets in this state a time interval 
which is picked up by the CPU and counted down in 
real time, at which time the CPU blocks the 
process, dumps its state in the context block and 
notifies the SCHEDuler that it has blocked. The 
SCHED processor does not deal with files. 



hJHSL 

The h M P swaps processes and files or portions 
of files included in a process working set. It 
also goes to disk when required to move files or 
processes to drum, and vice versa. Both core and 
drum are dynamically allocated. The locations of 
pages in these areas are kept track of in special 
hash tables in central memory keyed by the page 
unique names. Disk, on the other hand is 
allocated in a more static fashion: each page 
existing in the system has a fixed, permanent 
residence on disk. The location of each page on 
disk is determined when the page is created and 
remains so until the page is destroyed. 
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3.1 In terprocessor Communication 



In a multiprocessor system the processors by definition 
interact. The next several sections explore the nature of 
the communication between the 500 system processors. This 
communication closely parallels that between different 
modules of a conventional operating system. 

Basically the processors communicate by means of cen- 
tral memory, i.e., by changing bits in shared tables. To 
speed up a processor's having to look through extensive 
tables for changes, a hardware flag system is provided. 
This mechanism consists of a small number of latches in each 
processor which can be set by one or more other processors. 
The latches -- called request str_obes -- are tested and 
reset by each processor's microcode. Flags in central 
memory augment this rudimentary facility into a more general 
one . 



3.2 Processor Interlocking 
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The particular protect mechanism used is greatly 
simplified by the fact that each processor (and in fact* 
£vexi system component) is operated with a common clock. 
Thus processors make protect requests in exact synchronism. 
The hardware contention circuit shifts its notions of 
contention priority in such a way that each processor is 
treated with the same priority on the average. 



Page 18 



3.3 Illustration of Processor Interaction 



Figure 5 shows the processors (except SMP) and some of 
the more important communication signals between them. Each 
processor is dedicated to its own task and is designed to 
operate autonomously r independent of the other processors. 
No one processor is "in cntrol w of the other processors or 
of the system (except for, that is, the SMP which exercises 
its privileges only when a problem develops — see section 
xxxx on restarts ) . 



Figure 5. Schematic of Processor Interaction 



Consider the actions of the processors and the communi- 
cation between them in response to an interactive user 
typing a command on his terminal. We will assume that at 
this time his process is blocked for reasons of I/O and that 
the process is physically located on drum. 



1. CHIO 
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when the CHIO receives a wakeup character 
(say, EOL in our case), it initiates the sequence 
of events which are required to bring into 
execution the program the user is interacting 
with. The CHIO does this by passing a simple 
message to the SCHEDuler; a pointer to the 
appropriate process is placed into a small queue. 



2. SCHEDuler 

The message from the CHIO is retrieved by a 
dispatcher task in the SCHEDuler and passed to the 
SCHEDuler's WAKEUP task. This task just (1) 
records a bit which identifies the source of ^= 
"fra^d^gjHgS^-^ft^ " r * ti P fc~ 44i^>re~^ra^xi^_^pj^QXje-&^^ and (2) 
queues the process on a queue called the WAKEUP 
queue. 

An independent task (the SCHEDULING task) 
later removes the process from the WAKEUP queue 
and places it on the appropriate one of several 
SCHEDULER queues. Still another task removes the 
process from this queue and sends a message to the 
SWAPPER task in the MMP, requesting that the 
process be loaded into central memory. 




U*0>** // f* 



3. MMP 

The MMP, in response to the request from the 
SCHEDuler, sets about the task of reading the 
pro_cess jtjoiJuji£_jsxt_oJ^3^ 

T o STO "\ his it will have to create space in the 
central memory by writing out t h e__j^jjjELS— ~~-ai- 
previously active processes. /-— ' wTTelT** this rather 
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complex action has been completed* the MMP notes 
back to the SCHEDuler that the process is loaded. 
Note that during the time the MMP is reading pages 
of the process into memory, only, the MMP is 
concerned with the process. In particular, again, 
the CPUs are running other processes. 



4. SCHEDuler 

Loaded processes become the responsibility of 
the SCHEDler task called the MICRO-SCHEDULER. 
This is the module that actually controls the 
CPUs. it keeps track of the " priorities" of the 
processes executing on the CPUs and of the 
processes which are loaded and ready to be 
executed. When a CPU becomes available for our 
process (by virtue of its being free or because 
its current process has lower priority than ours) 
the MICRO-SCHEDULER hands the process to the CPU 
and tells it to run . 
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3.4 Explicit Communication Between the Processors 

In this section we consider the processor communication 
interfaces in more detail. We consider the various possible 
pairwise combinations. 



l . chio - CPUS 
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2. CHIO - SCHED 



This communication is only one way: from the CHIO to 
the SCHED. when the CHIO finds that it has collected a 
complete message for a process, i.e., when it gets a wakeup 
character from a terminal, the CHIO sends a notification to 
the SCHED. It does this by placing a short message 
containing the process' ID into the SCHED's message input 
buffer. This buffer is also used by the other processors in 
communicating with the SCHED to communicate a variety of 
things. A "wakeup message" from the CHIO must thus contain 
more than just the ID of the process for whom the CHIO has 
collected a message. It contains an "opcode" which means 
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that the message is a wakeup message plus a specification of 
the reason for the wakeup message. 

The CHIO sends wakeup messages to the SCHED for other 
reasons also. Among them are 

- the input buffers allocated to a process are (nearly) 
full 

- the output buffers allocated to a process are empty 
enough that the process can proceed to do more output 

- a special control character(a QUIT or ESCAPE character) 
has been received from the process' terminal. 

The SCHED's message input buffer is used by all the 
system processors. It is protected from simultanous access 
by means of one of the hardware PROTECTS. Thus, whenever a 
processor wants to reference this buffer, it first acquires 
the associated PROTECT, makes its reference (which only 
requires four or five memory references), and then releases 
the PROTECT. After placing a request in the buffer, the 
processor sets a request strobe latch in the SCHED to let it 
know that there is a message for it. 



3. CHIO - MMP 

These two processors have no need to communicate with 
each other. 



4. CPUs - MMP 

Message exchange between these two processors is always 
initiated "by the system code in a CPU making a request on 
the MMP. Messages from the MMP to the CPU are always 
responses to such requests. 

What the two processors talk Ak&ili are pages of memory. 
Each page in the memory system has been given a unique name 
at creation time. Pages are always referred to by name. For 
example the system code in the CPU makes such requests as 

- create a new page 

- destroy a page 
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The MMP has three separate message input "ports." Each 
port corresponds to a major task structure in the MMP. one 
is for the SWAPPER, one for a direct I/O capability (not a 
normal user's facility), and one is a utility task. 




Some requests require no response, and the system code 
in the CPU is finished once it has done the request strobe. 
Other requests initiate actions which require explicit 
responses and some of these call for immediate responses 
while others, taking longer to process, produce a delayed 
response . 




5. MMP - SCHED 

The MMP sends messages to the SCHED in the same way for 
the same basic reason the the CHIO does, i.e., to let the 
SCHED know that some event of interest to a process has 
occurred. Thus messages from the MMP to the SCHED are 
normally requests to wake up a specified process. Usually, 
some small amount of data for use by the process accompanies 
these messages . 

The SCHED sends messages to the MMP to request the 
swapping into or out of central memory of the working set of 
a process. It gives requests to the MMP the same way the 
CPU does -- by forming a message, appending it to the 
appropriate one of the MMP's message input queues (under a 
PROTECT), and then request strobing the MMP. 



6. CPU - SCHED 
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The CPU communicates with the SCHED for various 
reasons. The SCHED implements a real-time interrup t/wakeup 
facility for the use of user processes. At the request of 
such processes, the system code in the CPU calls this 
function in the SCHED to arrange that the process be 
awakened and notified at a certain real time. These 
requests are made by the CPU in the same way that the CHIO 
and MMP send wakeup message to the SCHED. The CPU seizes 
the appropriate PROTECT, puts a short message into the 
SCHED's message input buffer, releases the PROTECT, and 
request strobes the SCHED. 



Page 25 



4.0 DISCUSSION 
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Because so much fixed-algorithm computational power 
exists in the several management processors, it is possible 
to consider -- within those processors — the use of 
algorithms for various operating system functions which are 
too complex (i.e., time-sonsumpt i ve ) to utilize even ov very 
fast CPUs. Another consequence of the use of multiple 
microprocessors for system management is the ability to 
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utilize more straightforward coding techniques (since, for 
example, many "tricks" are used in conventional operating 
systems for efficiency). The coding is easier to do, is mor 
easily analyzed, and of course is less likely to fail. 
Finally, it is possible to include on a practical scale the 
use of redundant computations for operating system 
management which make error detection more immediate, give 
the system more survivability (is this the right term?), and 
greater fault locatabi li ty . 

)How do we discuss bringing up the 2nd CPU?) 
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APPENDIX I 



1.0 Intended Area of Applications 

A goal of BCC was to develop systems which could be 
used by £P_i£]LLe_i utilities « i.e., companies offering 
appropriately packaged computing power and services by means 
of telecommunications and remote terminals. The 500 system 
was intended to serve this purpose particularly where the 
computing jobs individually require small amounts of 
computation; that is, the system architecture was bi.as.ed 
toward accommodating large numbers of relatively small jobs. 
Common examples of intended applications were small 
scientific computations (e.g., small BASIC programs), 
bank-teller systems, reservations systems, real-estate sys- 
tems, etc. Many of these systems, while not requiring large 
amounts of computation, do require a large machine -- large 
in the sense of file capacity and memory address space. 
Thus a mini-computer, for example, would be ill-suited to 
the application, while a large machine might not be 
justifiable on economic grounds. 



[more: separate utilities, wholesaling, guaranteed service, 
data securi ty ) 



l.l User Machine and Operating System 

The operating is partitioned into functional areas and 
is executed on different processors concurrently. These 
processors are dedicated to their tasks. one type of 
processor is "dedicated, H of course, to the running of 
general-purpose (i.e., user-specified) code. This proces- 
sor, called a c_e_iU.r_aJL Processor « also executes portions of 
the operating system, always on behalf of its active user. 
Those CP characteristics of most interest from the operating 
system viewpoint are briefly listed below: 

- The CPs are designed to be programmed only in 
higher-level languages. There is no assembler 
for the CP . 
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Virtual memory: The CPs see a virtual memory of 
2 5 6 K words in pages of 2K each. 



Hierarchical* ring-structured 
mechanisms: 3 protection rings 
accommodate two levels of operating 
one for subsystems and user code, 
references acquire the protection of 
being addresses. 



protection 
designed to 
system and 

Inter-ring 
the ring 



Numerous addressing modes designed to facilitate 
efficient running of compiler-generated code. 
Heavy emphasis is made on the use of 
descriptors for common data structures such as 
strings, fields, and arrays. 



comprehensive function 
mechanism . Copies 
environments, creates and 



call and 
arguments 



return 
between 
stacks environments. 



- CP traps directly under user control. 



The principal features of the operating system are: 

A AAHitftl.* common to all user processes. 
Contains a bare minimum of calls and is as 
general as possible. Is intended to be a 
"kernel" for additional operating system code. 
Exists in highest protection ring. 

- A £!ility_t which can be tailored for individual 

users. Implements all of the user machine 
characteristics and executive command language. 
Runs in middle protection ring. 

- Subsystems and user code, running in lowest 

ring, can call utility or monitor just like 
they call their own functions, subject to the 
ring protection . 



Finally, the virtual machine seen by user code (the 
user machine) has the following general 
appearance : 

- A 128K address space 

- The usual types of operating system calls. 
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Some unusual calls such as: 

- User control over process working set 



- Scheduling decisions like whether to block 
for I/O. 
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1.2 Hardware 
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All of the processors -- the central-site processors 
and the remote-site processors -- are implemented around a 
basic microprocessor designed by BCC for use in the system. 
The microprocessors used in the central site have 24-bit 
wide arithmetic units, and each executes at a maximum rate 
of about twelve million operations per second. The 
remote-site processors had 16-bit arithmetic units and were 
slower. Each version uses discrete diode circuit boards for 
their control memory, which contains 2K x 90-bit words. 
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The drum and disk memory units are interfaced with the 
central memory by rather simple controllers termed "transfer 
units." Each drum is equipped for full parallel transfer at 
the rate of two megawords per second (six megabytes per 
second). The disk units transfer approximately ten times 
more slowly, or at about 600 kilobytes per second. 
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[The Aux Hem is considered to be part of 
memory" (as opposed to being I/O units)* 
... pages, unique names, etc.] 



the system 
and the data 



"main 
format 



